No actionable comments were generated in the recent review. 🎉

sequenceDiagram
  participant Heartbeat as Heartbeat Planner
  participant Collectors as extract_meeting_url_from_map
  participant Calendar as handle_calendar_meeting_candidate
  participant EventBus as DomainEvent Bus
  participant Redux as Redux / NotificationSlice
  participant Card as CoreNotificationCard
  participant RPC as agent_meetings_notification_action

  Heartbeat->>Collectors: collect_calendar_meetings(events)
  Collectors-->>Heartbeat: PendingEvent { meeting_url: Some(...) }
  Heartbeat->>Calendar: handle_calendar_meeting_candidate(meet_url, title)
  alt AskEachTime policy
    Calendar->>EventBus: publish MeetingSessionCreated
    Calendar->>Redux: dispatch CoreNotificationEvent { actions: [join, skip, alwaysJoin] }
    Calendar-->>Heartbeat: owns_notification = true
    Redux-->>Card: render action buttons
    Card->>RPC: openhuman.agent_meetings_notification_action { action_id, payload }
    RPC-->>Card: ok
    Card->>Redux: dispatch markRead + clearNotificationActions
  else Always policy
    Calendar->>EventBus: publish MeetingAutoJoinTriggered
    Calendar->>Calendar: spawn auto_join_meeting(listen_only_default)
    Calendar-->>Heartbeat: owns_notification = true
  else Never policy
    Calendar-->>Heartbeat: owns_notification = false
  end

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Code review — calendar-triggered auto-join + Meeting Assistant settings

Walkthrough. Adds a calendar-driven Meet auto-join flow: the heartbeat planner forwards imminent meetings to handle_calendar_meeting_candidate, which routes by auto_join_policy (Never/Always/AskEachTime), surfaces an actionable CoreNotificationCard in AskEachTime mode, and wires up a new Meeting Assistant settings panel + agent_meetings_notification_action RPC. The work is well-tested (URL extraction edge cases, policy ownership, payload builders, notification-action variants, settings apply, Vitest for the card/panel/service) and i18n parity is complete (27 keys × 14 locales). Overall solid; a few correctness/consistency items below.

Changed-files summary (highlights)

Major

1. Always policy has no per-meeting dedup → duplicate bot:join.
handle_calendar_meeting_candidate (calendar.rs, Always branch) spawns auto_join_meeting with a fresh correlation_id every call and creates no session — unlike the AskEachTime branch, which dedups via store::get_session_by_meet_url. The same imminent meeting reaches this function from multiple callers:

• The heartbeat planner forwards on two allow_external stages — final_call (0–10 min) and starting_now (0 to −10 min) in planner/plan.rs:34-57. Each is a distinct dedupe_key (keyed on stage), so mark_sent lets both through across ticks.
• The live Composio MeetCalendarSubscriber also calls it directly.

Net effect with auto_join_policy = Always: the bot can be told to join the same meeting 2+ times with different correlation IDs (so the backend can't dedup by correlation). Suggest mirroring the AskEachTime dedup in the Always branch — e.g. create/check a session (or a meet_url-keyed marker) before spawning the join:

AutoJoinPolicy::Always => {
    if let Ok(Some(existing)) = store::get_session_by_meet_url(&config, &meet_url) {
        if existing.status != MeetingSessionStatus::Ended {
            tracing::debug!(meeting_id = %existing.id, "[meet:calendar] already auto-joined — skipping");
            return false;
        }
    }
    // ...create a session, then spawn auto_join_meeting...
}

Major (pre-existing, now load-bearing)

2. Composio path extract_meet_url leaks free-form location strings — the exact case collectors.rs just fixed.
collectors.rs correctly added extract_meeting_url_from_text so a location like "Zoom Meeting: https://zoom.us/j/123" yields only the parseable URL (with a comment explaining that returning the whole string produces a meeting_url the join handler rejects). But the sibling Composio path extract_meet_url in calendar.rs:574-579 still returns the whole location string:

if let Some(loc) = root.get("location").and_then(|v| v.as_str()) {
    if is_meeting_url(loc) {
        return Some(loc.to_string());   // returns "Zoom Meeting: https://zoom.us/j/123"
    }
}

That string becomes the meetUrl in the AskEachTime action payload; when the user clicks Join, handle_notification_action → handle_join → validate_meeting_url runs url::Url::parse and fails. The buttons silently never work for Zoom/Teams-in-location events arriving via Composio. Reuse the same token-scan helper here (see nitpick #3 for de-dup).

Minor / nitpicks

3. MEETING_HOST_PATTERNS + is_meeting_url triplicated. Now defined in calendar.rs:532-541, collectors.rs:436-441, and as ALLOWED_HOSTS in ops.rs:21-26. Consider a single shared helper (and have both extractors funnel free-form text through one extract_meeting_url_from_text), which would also fix #2 for free.

4. extract_meeting_url_from_text doesn't strip a trailing period. The trim set covers ()[]<>,;"' but not ., so …link: https://zoom.us/j/123. keeps the trailing dot (which url::Url::parse accepts as path), yielding a slightly-off URL. Add . to the trim set.

Questions

• For Never, the generic "meeting starting" plain card still fires (by design per the doc comment). Intended that a user who set Never still gets heads-up cards? (Seems fine, just confirming.)

Looks good

• AskEachTime session-dedup, fail-closed fallbacks (config-load failure / session-create failure → plain reminder, returns false so the planner still notifies), and the effective_listen_only "no anchor ⇒ listen-only" safety rule are all well-reasoned and tested.
• CoreNotificationCard guards double-clicks (pendingActionId) and clears actions after success to prevent re-firing bot:join/always_join.
• auto_join_policy / auto_summarize_policy RPC parsing rejects unknown values with a clear error.
• i18n parity complete; settings route/icon/registry wiring consistent.

Read-only review — no changes pushed.

Addressed all four items from sanil-23's review (pending commit + push):

Major #1 — Always policy dedup: Added store::get_session_by_meet_url guard before spawning auto_join_meeting. If a non-Ended session already exists for the URL, we return early. Also create a Joined session (keyed by correlation_id) before spawning, so subsequent heartbeat ticks and Composio re-fires find the existing entry and skip. Session-create failure logs a warning but proceeds (best-effort dedup).

Major #2 — extract_meet_url location leaks free-form string: The location branch now calls extract_meeting_url_from_text (a new local helper mirroring the one in collectors.rs) instead of returning the raw loc string. Free-form locations like "Zoom Meeting: https://zoom.us/j/123" now yield only the parseable URL.

Minor #3 — MEETING_HOST_PATTERNS triplicated: Intentionally deferred as a follow-up refactor — consolidating across calendar.rs, collectors.rs, and ops.rs would cross domain boundaries and is pure cleanup. The correctness fixes (#1 and #2) are self-contained.

Minor #4 — extract_meeting_url_from_text missing trailing period: Added . to the trim_matches set in both collectors.rs and the new calendar.rs copy.

New tests cover: free-form label+URL extraction, paren/bracket stripping, trailing-period stripping, non-meeting locations, and the integration-level extract_meet_url with free-form location fields.

I re-checked the current head (af621df) against the blocking review items. The two correctness blockers appear addressed in code now:\n\n- Always-policy duplicate joins: src/openhuman/agent_meetings/calendar.rs now checks store::get_session_by_meet_url(&config, &meet_url) before spawning �ot:join, and skips when an active non-ended session exists.\n- Composio free-form location: �xtract_meet_url now routes the location field through �xtract_meeting_url_from_text, returning only a parseable http(s) meeting URL token. There are tests for free-form Zoom and Teams location strings.\n\nCurrent CI on #3721 is green, including Rust Quality, Rust Core/Tauri Coverage, Rust E2E, Frontend Quality/Coverage, Playwright shards, and Coverage Gate. The only unresolved GraphQL thread I see is the MeetingSettingsPanel rollback comment, which the current head also addresses with rollback callbacks and tests per the author reply.\n\nRequesting a reviewer re-check on the stale CHANGES_REQUESTED state.